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DETAILED ACTION 

Response to Arguments 

1 . Applicant's arguments submitted on 06/16/2004 with respect to claims 1-12 have 
been reconsidered but are not deemed persuasive for the reasons set forth below. 

Applicant argues (on page 8, under REMARKS section) that the references do 
not teach or suggest (a) creating on a server, a list of required structs based on a 
requirement of the client, (b) sending the list from the server to the client, and (c) 
processing, by the client, data represented by the list. 

Examiner respectfully disagrees. Nodushani teaches (a) creating on a server, a required 
struct based on a requirement of the client, ( i.e. 

"//module MTOAMP1 f 
// 

//structure definitions 

//Attributes for the Tl interface 

// 

struct Tl Attributes { 

unsigned short iflndex; 
Boolean primary; 
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interface Tl{ 

Tl Attributes getAttributes 0; 

}; 

}; " the preceding text/code excerpts clearly indicates that Tl Attributes is a definition of a struct 
and interface Tl has a method getAttributes() which returns Tl Attributes to the client. In a CORBA environment, an 
interface is a client stub that works as a proxy for the client. Here the client needs the Tl Attributes from the server 
and invokes the getAttributes() method and the server creates Tl Attributes and returns them to the client. It requires 
no further explanation.) (col 46; lines 15-24; col 50, lines 15-33) (b) Sending the Struct from the Server 

to the client, (col 46; lines 15-24; col 50, lines 15-33) and (c) processing, by the client, data 

represented by the Struct (i.e. the returned Tl Attributes from the server is for the client to process or 
whatever it wants to do with these.) (col 46; lines 15-24; col 50, lines 15-33). 

Rodriguez teaches that the Client requests a list (i.e. a sequence of Markers/ structs) of 
structs from the server (page 5). 



Claim Rejections - 35 USC § 103 

2. The following is a quotation of 35 U.S.C. 103(a) which forms the basis for all 
obviousness rejections set forth in this Office action: 



(a) A patent may not be obtained though the invention is not identically disclosed or described as set 
forth in section 102 of this title, if the differences between the subject matter sought to be patented and 
the prior art are such that the subject matter as a whole would have been obvious at the time the 



• 
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invention was made to a person having ordinary skill in the art to which said subject matter pertains. 
Patentability shall not be negatived by the manner in which the invention was made. 

3. Claims 1-12 are rejected under 35 U.S.C. 103(a) as being unpatentable over 
Nodoushani et al. (U.S. Patent No. 6,563,816 and Nodoushani hereinafter) in view of 
Rodriguez et al. ("A CORBA server for the Radiation Hybrid DataBase", 1997, pages 1- 
8 and Rodriguez hereinafter). 

As to claims 1 ,6,7,8,9 and 1 1 , Nodoushani teaches a method of operating a 

Communication network (i.e. the end-to-end system) (Fig. 28; col 38, line 65) With a network 
management System (i.e. "The CPA 42 further includes a home LAN manager 389, an SNMP (simple 
network management protocol) agent 390 and general UNIX administration utilities 388. Multiple HLHs 20 are 
managed from the CPA 42 through channels 362C to HL agents 380 to support all provisioning, maintenance and 
testing functions. ") (col 39, lines 12-17), wherein Said Communication network (Fig. 28; col 38, line 65) 
Comprises an Object (i.e. CORBA-based managed object) (col 2, lines 45-54; col 39, lines 24-29) On a 
Server (i.e. "According to an aspect of the invention, a network element includes a Common Object Request 
Broker Architecture (CORBA)-based server, CORBA-based managed objects accessible by the CORBA-based 
server and a CORBA-based applications programming interface (API). The CORBA-based API is coupled to an 
external operations support system which can manage the plural CORBA-based managed objects directly. " ... "A 
CORBA server 386 provides the "glue" for all management applications with information regarding provisioning 
382A, inventory 394, status 384A and alarms 396. ") (col 2, lines 45-54; col 39, lines 24-29), and wherein Said 

network management system (col 39, lines 12-17) is located on said server (col 2, lines 45-54; col 

39, lines 24-29) and Can be accessed by a Client (i.e. "Fig. 29 shows a configuration for CORBA-based 
flow through provisioning with the CORBA server 386 of CPA 42 and the aforementioned OSSs 397-1, 397-2, 397- 
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3, 397-4. " ... "There are several advantages of the CORBA-based configuration. For example, by basing the 
internal management scheme on CORBA, instead of raw memory, it is very easy to add new protocols as CORE A 
clients, such as BelCORE TL1 protocol if desired to inter-operate with OSSs. " ) (col 40, lines 10-27), Wherein 

said server and said client transmit data over said communication network in 
accordance with a Common Object Request Broker Architecture (CORBA) (col 2, lines 45- 
54; col 39, lines 24-29), and wherein said method comprises: accessing by said client, a 
descriptor for said object, wherein said descriptor is represented by a struct ( i.e. 

"//module MTOAMPI f 
// 

//structure definitions 

//Attributes for the Tl interface 
// 

struct T I Attributes { 

unsigned short iflndex; 
Boolean primary; 

h 

interface Tlf 



Tl Attributes getAttributes Q; 
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" ) (col 46; lines 15-24; col so, lines 15-33) that includes an attribute but no operation (i.e. 

the structure by definition does not contain any operation/method as in the prior art) (col 46; lines 15-24; col 50, 

lines 15-33); creating on said server, required struct based on a requirement of said client ( 

i.e. 

"//module MTOAMP1 { 
// 

//structure definitions 



//Attributes for the Tl interface 

// 

struct Tl Attributes { 

unsigned short iflndex; 
Boolean primary; 



h 



interface Tlf 



T I Attributes get Attributes Q; 



}; " the preceding text/code excerpts clearly indicates that Tl Attributes is a definition of a struct and 
interface Tl has a method getAttributes() which returns TIAttributes to the client. In a CORBA environment, an 
interface is a client stub that works as a proxy for the client. Here the client needs the TIAttributes from the server 
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and invokes the getAttributes() method and the server creates Tl Attributes and returns them to the client. It requires 
no further explanation.) (col 46; lines 15-24; col 50, lines 15-33) ; Sending Said required Struct from 

said server to said client (col 46; lines 15-24; col 50, lines 15-33); and processing, by said client, 

data represented by Said Struct (i.e. the returned Tl Attributes from the server is for the client to be 
processed or whatever it wants to do with these.) (col 46; lines 15-24; col 50, lines 15-33). 

Nodoushani does not explicitly teach an object stored in a database on a server 
and Nodushani does not teach that the client requests a list of structs from the server. 
Rodriguez teaches an object stored in a database on a server (page 4) and 

Rodriguez also teaches that the Client requests a list (i.e. a sequence of Markers/ structs) of structs 
from the server (page 5). 

It would have been obvious to a person of ordinary skill in the art at the time of 
Applicant's invention to modify the teachings of Nodoushani with the teachings of 
Rodriguez to include an object stored in a database on a server and the client 
requesting a list of structs from the server with the motivation to provide an application 
of CORBA technology to support external access to the database (Rodriguez, page 4). 

As to claim 2, Nodoushani teaches using a definition for an interface (col 50, lines 
60-65) that only includes an operation but not necessarily any attribute (i.e. 

"Interface RegisterClient { 

void signOn (in TrapFielder client); 



};") (col 50, lines 60-65). 
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As to claim 3, Nodoushani teaches including a reference to said struct in said 
interface ( i.e. 

"//module MTOAMPl { 

// 

//structure definitions 



//Attributes for the Tl interface 

// 

struct Tl Attributes { 

unsigned short iflndex; 
Boolean primary; 



}; 



interface Tl{ 



Tl Attributes get Attributes Q; 



h 



}; " ) (i.e. the above code excerpts show that the struct for the "Tl Attributes" is a descriptor for a 
corresponding interface with the name "Tl". The struct only comprises the attributes of the Tl, but not its operation. 
The operation of the Tl i.e. the getAttributes operation is contained in the definition of the "Tl". The attributes are 
referenced by the client via the Tl Attributes, which is defined in the described struct descriptor. The attributes are 
therefore accessible via the Tl Attributes without the need for a Tl. Another interface/client needs a reference to the 
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Tl Attributes to access/store the same attribute information as that which is defined in a known interface and is 
essentially depended on the particular need of the client application) (col 46; lines 15-24; col 50, lines 15-33). 

As to claim 4, Nodoushani teaches that an instruction from the client (i.e. 'Tig, 29 

shows a configuration for CORBA-based flow through provisioning with the CORBA server 386 of CPA 42 and the 
aforementioned OSSs 397-1, 397-2, 397-3, 397-4. " ... "There are several advantages of the CORBA-based 
configuration. For example, by basing the internal management scheme on CORBA, instead of raw memory, it is 
very easy to add new protocols as CORBA clients, such as BelCORE TL1 protocol, if desired to inter-operate with 

osss. " ) (col 40, lines 10-27) which is directed to the struct ( i.e. 

"//module MTOAMP1 { 
// 

//structure definitions 

//Attributes for the Tl interface 

1/ 

struct Tl Attributes f 

unsigned short iflndex; 
Boolean primary; 

h 

}; " ) (col 46; lines 15-24; col 50, lines 15-33) On the Server (i.e. "According to an aspect of the 

invention, a network element includes a Common Object Request Broker Architecture (CORBA)-based server, 
CORBA-based managed objects accessible by the CORBA-based server and a CORBA-based applications 
programming interface (API), The CORBA-based API is coupled to an external operations support system which 
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can manage the plural CORBA-based managed objects directly. " ... "A CORBA server 386 provides the "glue" for 
all management applications with information regarding provisioning 382A, inventory 394, status 384 A and alarms 
396. ") (col 2, lines 45-54; col 39, lines 24-29), results in Sending data ( i.e. 
"//module MTOAMP1 { 

interface Tl{ 

Tl Attributes getAttributes 0; 

}; 

}; " ) (col 46; lines 15-24; col 50, lines 15-33) from the Server (col 2, lines 45-54; col 39, 
lines 24-29) to the Client (col 40, lines 10-27). 

As to claim 5, Nodoushani teaches not storing the data sent to the client on the 

Server (i.e. "Tl Attributes getAttributes Q; ". The code excerpts show that the client invokes the getAttributes 
method and the server sends the attributes to the client in a struct but does not store them in the server.) (col 46; lines 
15-24; col 50, lines 15-33);. 

As to claim 10, Nodoushani teaches that the said computer program (col 46; lines 

15-24; col 50, lines 15-33) is Stored On a data Carrier (i.e. a computer or any other processor) (Fig. 28). 
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As to claim 12, Nodoushani teaches that the said computer program product (col 

46; lines 15-24; col 50, lines 15-33) is Stored On a data Carrier (i.e. a computer or any other processor) (Fig. 
28). 



Conclusion 

4. THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded 
of the extension of time policy as set forth in 37 CFR 1 .1 36(a). 

A shortened statutory period for reply to this final action is set to expire THREE 
MONTHS from the mailing date of this action. In the event a first reply is filed within 
TWO MONTHS of the mailing date of this final action and the advisory action is not 
mailed until after the end of the THREE-MONTH shortened statutory period, then the 
shortened statutory period will expire on the date the advisory action is mailed, and any 
extension fee pursuant to 37 CFR 1 .136(a) will be calculated from the mailing date of 
the advisory action. In no event, however, will the statutory period for reply expire later 
than SIX MONTHS from the date of this final action. 

Points of Contact 

5. Any inquiry concerning this communication or earlier communications from the 
examiner should be directed to Apu M. Mofiz whose telephone number is (703) 605- 
4240. The examiner can normally be reached on Monday - Thursday 8:00 A.M. to 4:30 
P.M. 
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If attempts to reach the examiner by telephone are unsuccessful, the examiner's 
supervisor, Dov Popovici can be reached at (703) 305-3830. The fax numbers for the 
group is (703) 872-9306. 

Any inquiry of a general nature or relating to the status of this application should 
be directed to the Group receptionist whose telephone number is (703) 305-9600. 

Apu M. Mofiz 
Patent Examiner 
Technology Center 2100 



September 28,2004 




